home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 479 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.5 KB  |  107 lines
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: Jamshid Afshar <jamshid@IO.COM>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Destruction of singletons
  5. Date: 25 Feb 1996 00:09:02 GMT
  6. Organization: Illuminati Online, Austin, Texas, USA
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4go9au$l8f@engnews1.Eng.Sun.COM>
  9. References: <4fvng1$jit@netlab.cs.rpi.edu>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Originator: clamage@taumet
  12.  
  13. In article <4fvng1$jit@netlab.cs.rpi.edu>,
  14. Bob Archer  <bob@hottub.demon.co.uk> wrote:
  15. >Singleton * Singleton::Instance() {
  16. >  if (_instance == 0) 
  17. >      _instance = new Singleton;
  18. >  return _instance;
  19. >}
  20. >
  21. >[Jamshid] suggested that using a static local variable might be better:
  22. >
  23. >Singleton * Singleton::Instance() {
  24. >  static Singleton s;
  25. >  return &s;
  26. >}
  27. >
  28. >James Kanze then replied:
  29. >    Although I tend to prefer this idiom too, it is important to realize
  30. >    that there are some cases where it is preferable *not* to destruct the
  31. >    variable.  (If there is only one, this shouldn't constitute a memory
  32. >    leak.)  [...]
  33. >
  34. >Why does the fact that only one variable is involved mean that this is 
  35. >not a memory leak?
  36.  
  37. James has responded that although technically it is a memory leak,
  38. it's not important unless you're using a poor operating system that
  39. does not recover all memory when a process finishes.  I agree I
  40. wouldn't want to use such an operating system (Win3.1?), but I think
  41. it is sloppy programming to not ensure all the objects you create get
  42. destroyed and all the memory you allocate gets deleted.  Of course
  43. there are probably cases where this is not possible or practical, but
  44. leaked memory and undestroyed objects cause hassles when using
  45. debugging tools like Purify which report all memory leaks when the
  46. program finishes.  You'll get enough leak reports from sloppy 3rd
  47. party libraries -- you shouldn't be adding a bunch "ignore this leak,
  48. I 'know' it's okay" configuration statements for the code you write.
  49. Also, you may sometime soon want to remove the "singleton" restriction
  50. on the class -- IMO get it right the first time and make sure its
  51. destructor works properly.
  52.  
  53. >I take the point about the Singleton object possibly being used in the 
  54. >destructors of a static object. Is there any way to ensure that the 
  55. >singleton will be destroyed but only after everything that might wish 
  56. >to use it has been destroyed ? (I guess that this is just the usual 
  57. >problem with the order of global construction / destruction ).
  58.  
  59. Actually, the construction and destruction of "local objects of static
  60. storage duration" is not the same as objects outside of functions.  In
  61. fact, it seems local statics are more poorly specified.  According to
  62. the April '95 Draft, while they are guaranteed to not be constructed
  63. until (and if) the function is called, exactly when the destructor is
  64. called is unspecified.  At least globals are sensibly guaranteed to be
  65. destroyed in the reverse order they were constructed.  What should
  66. have been required IMO is that local statics be destroyed in the
  67. reverse order they were (fully) constructed.  For example, if the
  68. constructor of a local static "g_list" calls a function containing
  69. another local static "g_log", g_list should be destroyed first since
  70. its construction was finished last.  This is desirable behavior since
  71. g_list's destructor may also use g_log.
  72.  
  73. With the committee leaving destruction order of local statics
  74. unspecified, you'll have to instead dynamically allocate the singleton
  75. and use atexit() to delete it if you have singletons referring to each
  76. other in their constructor or destructor code.  Note: atexit()
  77. functions are called in the reverse order they were registered.
  78.  
  79.     class LogFile {
  80.     public:
  81.        LogFile& theLog() {
  82.           if (!p) {
  83.              p = new LogFile;
  84.              atexit(&destroy);
  85.           }
  86.           return *p;
  87.        }
  88.     private:
  89.        static LogFile* p;
  90.        void destroy() { delete p; }
  91.     };
  92.  
  93. Is there any reason the committee chose not to have local statics do
  94. this kind of ordering automatically?  Of course, it won't solve every
  95. problem related to "global" construction/destruction ordering, but it
  96. seems a lot better than leaving it unspecified and doesn't seem like
  97. it would have placed any burden whatsoever on implementors.
  98.  
  99. Jamshid Afshar
  100. jamshid@io.com
  101. [ To submit articles: Try just posting with your newsreader.
  102.               If that fails, use mailto:std-c++@ncar.ucar.edu
  103.   FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  104.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  105.   Comments? mailto:std-c++-request@ncar.ucar.edu
  106. ]
  107.